Every developer should have a bookshelf. The possible set of texts in his cabinet are myriad, but not every collection gives a programmer a variety of tools. With an eclectic set of weapons, a developer can attack a problem from multiple angles. This mélange of approaches is made possible through a diverse bookshelf.  A varied closet is provided by the works listed below.

Overview

This section’s books provide a bird’s-eye view of the techniques in the developer’s standard toolkit.

Code Complete

Steve McConnell’s Code Complete is an overview of the programmer’s basic toolbox.  That workbench includes planning, design, coding, and QA. These topics, and others, are given an outline by McConnell. His sketches provide best practices for many subjects.  The recommendations and synopses in Code Complete form the developer’s standard toolkit.

Facts and Fallacies of Software Engineering

Robert Glass’ Facts and Fallacies of Software Engineering is a collection of cases for the common workbench. Each insight provides a description, a characterization of any controversies, and sources to consult.  These elements introduce many software engineering topics.  These areas are essential to a basic toolbox. The standard set of tools is expanded by Glass’ facts. His book Facts and Fallacies of Software Engineering is necessary reading for any developer.

Mythical Man Month

Frederick Brooks’ The Mythical Man-Month adds foundational insight to the baseline toolkit. This wisdom takes the form of maxims more than numbers. Brooks’ data may not be correct, although his intuition is. Brooks’ instinct leads him to assert that software written for others requires more effort than programs written for the developer. His hunch matches the experience of most programmers. A software engineer might quibble with Brooks’ cited magnitude difference, but he still concedes that the gap is nontrivial. The point about that disparity, and others, are the insights that The Mythical Man-Month adds to the basic development tool belt.

Understanding Decisions, Ideas, and Thought

The tomes in this area extend the basic workbench with methods that provide insight into the headspace of humans.

Knowledge and Decisions

Thomas Sowell’s Knowledge and Decisions expands the standard bag of tricks with a sketch of human knowledge and decision-making.  Expertise is distributed.  The know-how required to make decisions is dispersed. The proficiency to make every choice is not held by one person, or even a few people. Many individuals are required for effective decision-making to occur, a point that Sowell drives home through many chapters. His book Knowledge and Decisions provides an essential portrait of human intuition and judgement.

Rational Optimist

Matt Ridley’s The Rational Optimist augments the basic toolkit with a picture of interpersonal exchanges of knowledge. A transaction of expertise leaves each person involved with a surplus of skills. In fact, new abilities can be devised, when knowledge is combined. Some of that expertise might not have been available to the inventor, if human beings had not engaged in an exchange of their respective insights.  Understanding these transactions is a useful tool for developers. Programmers can add this technique to their toolboxes by reading The Rational Optimist.

Psychology of Computer Programming

Gerald Weinberg’s The Psychology of Computer Programming widens the standard workbench with an image of the headspace of programmers, their environment, and their tasks. For example, software engineers may be motivated by the challenge of a job instead of money.  The task itself has some unexpectedly difficult elements such as specifications. Aspects of programming and programmers can be counterintuitive. Yet, parts of the engineering environment such as managerial hierarchies are more conventionally challenging.  The world of software development has its own portrait. That picture is a useful one to have in the tool belt. To add that sketch to the workbench, read The Psychology of Computer Programming.

General Problem Solving

These volumes bolster the existing arsenal with ways to assault problems generally or development issues broadly.

Introduction to General Systems Thinking

Gerald Weinberg’s An Introduction to General Systems Thinking amplifies the existing toolkit with general approaches to puzzles. These methods stem from the general systems philosophy. This doctrine looks for the underlying similarities across a multitude of disciplines. These cross-specialty parallels supply a number of useful attacks.   For example, abstraction and decomposition provide assaults on the complexity inherent to subjects such as physics. The topic of computer programming could certainly benefit from the techniques of the general systems philosophy.  To add these methods to the arsenal, read An Introduction to General Systems Thinking.

Pragmatic Programmer

Andrew Hunt and Dave Thomas’ The Pragmatic Programmer boosts current the toolbox with a general collection of practical approaches to common problems.  For example, the issue of the distance between a solution and its target can be addressed through a tracer bullet. If a solution, the bullet, or even the target is a question, then a team can answer that query with a prototype or a set of prototypes.  These mechanisms are only a few in the assortment provided by The Pragmatic Programmer.

Useful Non-Software Disciplines

This region’s texts enhance the existing tool belt with approaches from non-software disciplines.

Economics in One Lesson

Henry Hazlitt’s Economics in One Lesson enhances a developer’s workbench with the basic concepts of economics. The dismal science is an area of study permeated by equations, graphs, and charts.  These elements are not prominent in Hazlitt’s book.  He prefers to explain economics through concepts rather than numbers. The primary idea is “the seen and the unseen.” The observed are the first order costs and/or benefits. The unobserved are the higher order outlays and/or gains. The detected effects are the direct outcomes, while the undetected consequences are the second, third, and fourth order results. These events and their perception are discussed the book’s various chapters. Hazlitt’s Economics in One Lesson adds the concepts of economics to a programmer’s arsenal.

How to Think Straight about Psychology

Keith Stanovich’s How to Think Straight About Psychology extends the developer’s toolkit with various scientific techniques. Science is not in the title of Stanovich’s book.  Yet, his book is actually a primer on scientific tools.  The author applies them to psychology, but he could have easily applied them to any other field. Software development could just as easily use a primer on methods such as random sampling, blinding, experimental controls, etc. To understand these approaches in detail, read How to Think Straight About Psychology.

Innumeracy

John Allen Paulos’ Innumeracy gives programmers basic statistical tools. Developers can do basic math. Yet, skills with numbers are not simply what Paulos’ book attempts to provide. Innumeracy tries to give its reader the ability to reason mathematically, an ability that human psychology can make difficult. The capability to think about numbers clearly is hampered by human intuition, a phenomenon that Paulos explains. Innumeracy demonstrates how a person’s instincts and statistics might reveal different answers. This difference in results is what Paulos tries to drive home. He wants to provide his readers with the tools guard against the errors of their own intuition. The gut feelings of programmers are no better than the instincts of non-programmers.  Software engineers need the skills that Innumeracy provides as much as anyone else does.

The Development Process

The books in this section add to the current toolbox techniques associated with software development processes.

The Incremental Commitment Spiral Model

Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, and Richard Turner’s The Incremental Commitment Spiral Model presents developers with procedural approaches. These methods include a process and several principles. The system is less applicable than the principles are. The rules can be used to augment an existing strategy, while the scheme requires implementing one from scratch, a difficult task.  The job of expanding a programmer’s process with certain ideas is an easier undertaking than implementing a procedure is. To update a system with those principles, read The Incremental Commitment Spiral Model.

Balancing Agility and Discipline

Barry Boehm and Richard Turner’s Balancing Agility and Discipline provides developers with the ability to avoid various process-centric pitfalls.  For example, agile procedures sometimes fall into the trap of failing to keep an overview of the product in mind.  This risk can be avoided by keeping an updated summary of the software. The addition of a sketch to an agile process is a capability that avoids a danger common to such schemes.  Tools to avoid procedure-based difficulties are what Balancing Agility and Discipline provides to programmers.

Product Design

These tracts enlarge the current workbench with mechanisms to aid in the design of software.

Large-Scale C++ Software Design

John Lakos’ Large-Scale C++ Software Design bolsters the existing toolbox with methods for building sizable software.  Big products require techniques different from small commodities. Massive systems require special attention to testing and organization. Shortfalls in those areas generate costs that are significant in substantial software but are insignificant in minuscule programs. Sizable products require techniques to avoid expenditures due to deficiencies in verification and design. These outlays are bypassed by the methods provided in Lakos’ book. One recommended approach is an architecture with an acyclic dependency-graph whose elements are labeled according to a level-system. A layering-scheme and an acyclic diagram allow independent and orderly testing, reducing the cost of verification and validation.  These techniques for reducing that cost, and other problems associated with large software, are provided by Large-Scale C++ Software Design.

Don’t Make Me Think

Steve Krug’s Don’t Make Me Think widens the current tool belt with skills for designing a less painful user experience.  A person’s engagement with software can be fraught with difficulty.  One common hindrance is determining a means of achieving one’s goal. These mechanisms should not require much thought, but they frequently do.  Thinking makes a user experience painful.  Reducing unnecessary reflection eases that discomfort.  Tools for diminishing displeasure are what Krug’s Don’t Make Me Think provides.  These approaches can broaden the workbench of any programmer.

Code Design

This section’s volumes boost the existing arsenal with methods to help with the arrangement of code.

Agile Software Development, Principles, Patterns, and Practices

Robert Martin’s Agile Software Development, Principles, Patterns, and Practices enlarges the current armory with abilities targeted towards object-oriented design. These skills are described by the acronym: SOLID.  The phrase is a rubric for several principles of object-oriented design. These doctrines attempt to make object-based software flexible and maintainable.  Malleable and sustainable products are a common goal. To that end, Agile Software Development, Principles, Patterns, and Practices should enhance the toolkit of many software developers.

Design Patterns: Elements of Reusable Object-Oriented Software

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides’ Design Patterns expands the existing arsenal with attacks against common, code-related enemies. For example, some construction-related adversaries can be defeated through various builder and factory patterns.  Other devices can be used to beat structural and behavioral foes. Many code-adjacent antagonists can be felled though reusable motifs. To find some of these arrangements, read Design Patterns.

Security

The tomes in this category support current the set of tools with various means to confront security issues.

Threat Modeling

Adam Shostack’s Threat Modeling bolsters the current array with a system for approaching software security.  This scheme is called a threat modeling. It endeavors to construct a threat a model. That blueprint is used to enumerate security-related dangers. Each risk is mitigated, accepted, or transferred.  Each means of mitigation, acceptance, or transference is tested.  Threat modeling provides a systematic approach to security. To learn more about that method, read Shostack’s Threat Modeling.

24 Deadly Sins of Software Security

Michael Howard, David LeBlanc, and John Viega’s 24 Deadly Sins of Software Security expands a programmer’s workbench with techniques for common security problems. The book addresses some typical issues such as buffer overflows, cross-site-scripting, and SQL injection. These complications are prevalent enough that any developer needs a way to handle them.  Some of those paths are provided by 24 Deadly Sins of Software Security.

Coding

These texts enlarge the current collection of techniques with approaches aimed specifically at coding.

Clean Code

Robert Martin’s Clean Code provides a set of practices for writing hygienic methods and classes. Martin’s procedures help to wash away some of code’s dirt and grime. Filth has a way of creeping into software. Some methods become too long. Some classes gain too many entanglements. These pieces of code accumulate muck over time.  To wash that gunk away or to prevent it from piling up, follow the routines in Clean Code.

Wrap-up

Many attacks are required to handle the complicated problems of developing software well. Software engineering requires a large, eclectic arsenal. Building that armory requires time. The days and minutes necessary to read every book in every section listed here are large. Learning every tome takes many more months and years. Time is incremental. Reserve a few hours and minutes every day to learn a chunk of the areas described here.  These categories are not meant to be mastered in a year let alone a month, day, or hour.